03. git commit
快速检测
Task Description:
我们即将提交首个 commit,先进行以下验证以确保我们的项目设置相同:
Task Feedback:
很棒!
## 最后一次 git 状态检查
如果你尚未向工作目录添加任何文件或修改任何现有文件,则不会有任何被修改内容,但是为了进行确认,我们需要在提交 commit 之前再次快速运行下
git status
,以确保项目是我们预期的状态。
终端显示 index.html、css/app.css 和 js/app.js 已被暂存,并准备好被提交。
提交 Commit
我们开始提交吧!
要在 git 中提交 commit,你需要使用
git commit
命令,但是先别运行这条命令。运行这条命令将会打开你在第一节课配置的代码编辑器。如果你尚未运行以下命令:
$ git config --global core.editor <your-editor's-config-went-here>
回到 git 配置步骤并让 git 使用你所选的编辑器。
如果你尚未执行这一步骤并且已经运行
git commit
,那么 git 可能会默认使用 Vim 编辑器。Vim 很受 Unix 或 Linux 系统用户的欢迎,但是对新用户来说,并不太好用。这门课程肯定不推荐使用该编辑器。请参阅这篇关于
如何退出 Vim
的帖子,了解如何回到普通的命令提示符界面。
如果你配置了编辑器,那么可以使用
git commit
命令提交 commit:
$ git commit
注意,你的编辑器应该会打开并且会出现以下界面:
代码编辑器显示默认的 commit 消息内容,并等待提供提交说明。
终端冻结了
如果你快速切回终端,会看到终端冻结了,并等待你在弹出的代码编辑器完成编辑。不用担心。当我们向代码编辑器添加必要的内容,并最终关闭代码编辑器窗口后,终端将不再冻结,并回到正常状况。
终端显示
git commit
,但是似乎被挂起并在等待中。
代码编辑器 Commit 消息解释说明
回到代码编辑器。我的编辑器显示了以下内容:
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch master
#
# Initial commit
#
# Changes to be committed:
# new file: css/app.css
# new file: index.html
# new file: js/app.js
#
第一段精确地告诉了我们需要执行的操作 - 我们需要为该 commit 提供一条消息。此外 ,任何以字符
#
开头的行将被忽略。在后面还提示:这将是初始 commit。最后,给出了将提交 commit 的文件列表。
因为这是存储库的第一个 commit,我们将使用 commit 消息 "Initial commit"。文本 "Initial commit" 并不特殊,只是第一个 commit 的常用消息。如果你想使用其他消息,完全可以!
在代码编辑器的第一行输出 commit 消息:
在第一行输入了提交说明的代码编辑器。
完成提交
现在保存文件并关闭编辑器窗口(只关闭面板/标签页还不够,你还需要关闭
git commit
命令打开的代码编辑器窗口)。
现在回到终端,你应该能看到类似于以下内容的界面:
关闭代码编辑器后的终端。它显示了新 commit 的 SHA 以及关于该 commit 的信息,例如被添加的文件以及添加了多少行代码。
终于提交了第一个 commit,恭喜!
你刚刚提交了第一个 commit - 哇! 🙌🏼 有何感受?是不是有点虎头蛇尾的感觉。说实话,当我第一次提交 commit 时,我的感受就如同
“等等…就这样?只是把将要进行提交的文件添加到了暂存区,然后运行 'git commit'?”
答案是 “是的”。是的,就这些内容。一开始,你会觉得版本控制是一个要克服的庞大障碍,然后才能成为真正的程序员/开发者/设计师等等。但是当你理解术语(我认为是最具挑战的部分)后,实际运用版本控制就不是那么可怕了。
使用
-m选项绕过编辑器
提示:如果你要编写的提交说明很简短,不想等打开代码编辑器后再输入信息,可以直接在命令行中使用
-m选项传入信息:
$ git commit -m "Initial commit"
在上述示例中,文本
"Initial commit"被作为提交说明信息。但是注意,不能为 commit 提供信息的描述(description),只能提供信息部分(message)。
第二个 commit - 添加更改
我们已经短暂休息了一下,现在提交第二个 commit!将以下内容添加到
index.html
中的
body
标记中:
<header>
<h1>Expedition</h1>
</header>
下一步是什么?没错,运行
git status
!
终端显示了
git status
命令的结果。它显示了"Changes not staged for commit"部分,其中包含修改后的"index.html"文件。
提示:如果你运行了
git status,但是没有看到index.html已更改,确保文件已被保存。我经常在修改文件以后忘记保存文件!我觉得修改文件后是否记得保存是衡量真正的专业人士的标准。
具有多个作用的 git add
我们修改了文件。git 看到该文件已被修改。到目前为止,一切正常。注意,要提交 commit,待提交的文件必须位于暂存区。要将文件从工作目录移到暂存区,我们应该使用哪个命令?答对了,是
git add
!
我们使用
git add
向暂存区添加了新建的文件,同样的,我们也能使用同一命令将修改的文件暂存。
现在使用
git add
命令将文件移到暂存区,并使用
git status
验证文件是否位于暂存区。
第二个 commit
现在我们的文件已经具有可以提交的更改,让我们提交第二个 commit 吧!使用
git commit
命令提交 commit,并添加提交说明
Add header to blog
。
现在,你可能会问自己:“Richard 为何会这样书写提交说明?” 或 “何为好的提交说明?”。问的好,我们将在下一部分探讨这些问题!
会对文件进行 commit 吗?
SOLUTION:
否commit 中应该包含什么内容
我一直在告诉你要创建什么文件,提供需要要包含的内容,并告诉你何时应该进行 commit。但是你自己知道应该在 Commit 中包含什么内容,以及何时/多久进行 commit 吗?
关键在于使每个 commit 都有其侧重点。 每个 commit 应该记录一项更改。这种说法可能比较主观(完全没问题),但是每个 commit 应该只对项目的一个方面做出更改。
这并不限制可以添加/删除多少行代码或添加/删除/修改多少个文件。假设你想更改侧栏,并向其中添加新的图片。你可能会:
-
向项目文件中添加新的图片
-
更改 HTML
-
添加/修改 CSS 以包含新图片
完全可以使用一个 commit 记录所有这些更改!
但是,一个 commit 不应包含不相关的更改,更改侧栏,然后重新描述脚注内容。这两项更改相互没有关系,不应包含在同一 commit 中。先进行一项更改,提交该更改,然后再进行第二项更改。这样的话,如果一个更改有 bug,你需要撤消该更改时,则不用同时撤消另一个更改。
我认为在判断应该在 commit 中包含什么内容时,最好的方法是思考下“如果该 commit 中的所有更改都清空了,会怎样?”。如果删除了某个 commit,应该只撤消一项更改。
别担心,commit 不会随机地被清除。
在后面的课程中,我们将学习使用 git 撤消 commit 中进行的更改,以及如何谨慎地手动删除最后提交的一个 commit。
git commit 小结
git commit
命令会取出暂存区的文件并保存到仓库中。
$ git commit
此命令:
-
将打开配置中指定的代码编辑器
-
(请参阅第一节课中的 git 配置流程,了解如何配置编辑器)
在代码编辑器中:
-
必须提供提交说明
-
以
#开头的行是注释,将不会被记录 -
添加提交说明后保存文件
-
关闭编辑器以进行提交
然后使用
git log
检查你刚刚提交的 commit!
深入研究
-
将文本编辑器与 git 相关联 - 英 GitHub 帮助文档